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Description 

Field of the Invention 

This invention relates in general to computer soft- $ 
ware, and in particular to a method and system for en- 
abling multi-user collaboration over the World-Wide 
Web. More particularly, the present invention relates to 
a method and system by which awareness, touring, and 
conferencing can be performed in a portable manner. 

Background of the Invention 

Two techniques are in use today for delivering data 
from a supplier to a consumer: "push 0 and "pull". Under 
a "push" model, which is used by services such as Point- 
Cast, Castanet, and TIB, information is sent to the re- 
cipient whenever it becomes available at the source. 
Under a ■pull" model, which is used by services such as 
Excite, the data is only transmitted to the recipient in 
response to an explicit request. These two methods ex- 
cel at a variety of data retrieval tasks, from supporting 
random searches ("pull") to delivering dynamic informa- 
tion updates ("push"). 

However, these data retrieval metaphors are insuf- 
ficient to support real-time collaboration among multiple 
users over the Internet. Such applications include 
shared whiteboards, text and audio chat, shared slide 
shows, video, distance learning, and collaborative 
browsing of Web pages. These applications are charac- 
terized by the need to establish user groups and ex- 
change information to ensure that alt members of a par- 
ticular group see consistent information (e.g. see the 
same whiteboard image, see and hear each others' text/ 
audio, see slides/video in a synchronized manner, see 
the same Web page, etc). In effect, the consistent 
shared state updates are "pushed" to each client. At the 
same time, we need to provide freedom for each user 
to retrieve information by downloading arbitrary Web 
pages (a "pull" metaphor) and presenting that informa- 
tion to the collaborative application and group. 

Typically, these collaborative systems run as stand- 
alone applications because of their need to exchange 
specific data types and their special "push" and "pull" 
requirements. Indeed, these applications provide their 
own custom user interface and do not interoperate with 
existing tools. 

Systems like America Online's "Virtual Places" (VP) 
system have attempted to integrate collaboration into 
existing World-Wide Web browsers such as Netscape 
Navigator When the collaboration requires the user to 
see a new Web page or slide, this system communicates 
directly with the Web Browser and instructs it to display 
the particular Web page. To perform this communica- 
tion, VP relies on a Dynamic Data Exchange (DDE) in- 
terface exported by the particular Web Browser. DDE 
enables applications to exchange a pre-defined set of 
events, as supported by the particular endpoint applica- 



tions. 

The use of DDE restricts the VP functionality, how- 
ever. First, DDE is only available on Microsoft Windows 
platforms. Furthermore, because the DDE interface is 
application-specific, the particular interface used by VP 
only works with the Netscape Navigator browser. In 
summary, the VP system does not provide a portable 
mechanism for integrating collaboration with the World- 
Wide Web. 

Therefore, a need exists for a method and system 
for portably adding collaboration capabilities (both 
"push" and "pull" of information) to World-Wide Web 
content. In particular, a persistent connection is to be 
maintained to a shared state server for retrieving data 
via a "push" mechanism which maintains the freedom 
to access arbitrary Web content via the "pull" mecha- 
nism. Moreover, the collaboration should be provided in 
a portable manner, in the same way that all other Web 
content is portable both across hardware platforms and 
across browser implementations. 

Summary of th© Invention 

It is an object of the present invention to provide a 
technique which alleviates the above drawbacks. 

According to the present invention we provide a 
method of retrieving data from an information server, 
comprising the steps of: a requester initiating a request 
for data from an information server; sending said re- 
quest to a Proxy; said Proxy forwarding said request to 
said information server; said Proxy receiving and storing 
data from said information server inserting an Applet 
into said data; delivering said data and said Applet to 
said requester of said data; and executing said Applet. 

Further according to the present invention we pro- 
vide a system for retrieving data from an information 
server, comprising: means for a requester initiating a re- 
quest for data from an information server; means for 
sending said request to a Proxy; means for said Proxy 
forwarding said request to said information server; 
means for said Proxy receiving and storing data from 
said information server; means for inserting an Applet 
into said data; means for delivering said data and said 
Applet to said requester of said data; and means for ex- 
ecuting said Applet. 

Also according to the present invention we provide 
a computer readable storage medium having computer 
readable program code means for retrieving data from 
an information server, the computer readable program 
code means comprising: computer readable program 
code means for a requester initiating a request for data 
from an information server; computer readable program 
code means for sending said request to a Proxy; com- 
puter readable program code means for said Proxy for- 
warding said request to said information server; compu- 
ter readable program code means for said Proxy receiv- 
ing and storing data from said information server; com- 
puter readable program code means for inserting an Ap- 
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plet into said data; computer readable program code 
means for delivering said data and said Applet to said 
requester of said data; and computer readable program 
code means for executing said Applet. 

These and other features, aspects, and advantages 5 
of the present invention will become better understood 
with reference to the following description, appended 
claims, and accompanying drawings. 

Brief Description of the Drawings w 

For a more complete understanding of the present 
invention and for further advantages thereof, reference 
is now made to the following Detailed Description taken 
in conjunction with the accompanying drawings, in *5 
which: 

Figure 1 is a pictorial representation of a data 
processing system which may be utilized to imple- 
ment a method and system of the present invention; 20 

Figure 2 shows the data processing elements of a 
collaborative system that integrates with Web 
Browsers in a platform-independent manner; 

25 

Figure 3 is a flowchart depicting the steps required 
for delivering data from a Web Server to a Web 
Browser in a collaborative environment; 

Figures 4A, 4B, 4C and 4D are flowcharts illustrat- 30 
ing the actions performed by the inserted Applet 
when it executes in the Web Browser; 

Figure 5 is a flowchart illustrating how a user joins 
a Tour; and 3s 

Figure 6 is a flowchart illustrating how a user is no- 
tified when a Tour leader moves to a new Web page. 

Detailed Description of the Invention -to 

Referring to Figure 1, there is depicted a graphical 
representation of a data processing system 8, which 
may be utilized to implement the present invention. As 
may be seen, data processing system 8 may include a *s 
plurality of networks, such as Local Area Networks 
(LAN) 10 and 32, each of which preferably includes a 
plurality of individual computers 1 2 and 30, respectively. 
Of course, those skilled in the art will appreciate that a 
plurality of intelligent Work Stations (IWS) coupled to a 50 
host processor may be utilized for each such network. 
Each said network may also consist of a plurality of proc- 
essors coupled via a communications medium, such as 
shared memory, shared storage, or an interconnection 
network. As is common in such data processing sys- 55 
terns, each individual computer may be coupled to a 
storage device 1 4 and/or a printer/output device 1 6 and 
may be provided with a pointing device such as a mouse 



17. 

The data processing system 8 may also include 
multiple mainframe computers, such as mainframe 
computer 18, which may be preferably coupled to LAN 
1 0 by means of communications link 22. The mainframe 
computer 18 may also be coupled to a storage device 
20 which may serve as remote storage for LAN 10. Sim- 
ilarly, LAN 10 may be coupled via communications link 
24 through, a sub-system controi unit/communications 
controller 26 and communications link 34 to a gateway 
server 28. The gateway server 28 is preferably an IWS 
which serves to link LAN 32 to LAN 10. 

With respect to LAN 32 and LAN 10, a plurality of 
documents or resource objects may be stored within 
storage device 20 and controlled by mainframe compu- 
ter 18, as resource manager or library service for the 
resource objects thus stored. Of course, those skilled in 
the art will appreciate that mainframe computer 18 may 
be located a great geographic distance from LAN 1 0 and 
similarly, LAN 10 may be located a substantial distance 
from LAN 32. For example, LAN 32 may be located in 
California while LAN 10 may be located within North 
Carolina and mainframe computer 18 may be located in 
New York. 

Software program code which employs the present 
invention is typically stored in the memory of a storage 
device 14 of a stand alone workstation or LAN server 
from which a developer may access the code for distri- 
bution purposes, the software program code may be 
embodied on any of a variety of known media for use 
with a data processing system such as a diskette or CD- 
ROM or may be distributed to users from a memory of 
one computer system over a network of some type to 
other computer systems for use by users of such other 
systems. Such techniques and methods for embodying 
software code on media and/or distributing software 
code are well-known and will not be further discussed 
herein. 

Referring to Figure 2, the basic elements of a col- 
laborative system that integrates with a Web Browser 
are shown. A Multi-User Shared State Server (MUSSS) 
201 provides collaboration services on behalf of a set of 
users. This server is responsible for facilitating the ex- 
change of information among collaborators. Although 
not shown, it is to be understood that the MUSSS may 
comprise a plurality of interconnected servers that to- 
gether provide the services offered by a MUSSS. 

A Proxy 202 runs on each client host. It includes 
Client Software 203 that communicates with the 
MUSSS 201. Although the Proxy resides on the client 
host in the preferred embodiment, alternative embodi- 
ments may place the Proxy on other hosts, such as on 
a well known server. Over this communication, a client 
provides information to the collaborative session and re- 
ceives information from other participants in the collab- 
oration. The Proxy 202 also contains Forwarding Soft- 
ware 204 that receives Web page requests from a local 
Web Browser 205 and forwards them to an appropriate 
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destination Web Server 206. The Forwarding Software 
204 manipulates the retrieved data before delivering it 
to the Web Browser 205. 

Finally, the Web Browser 205 displays the retrieved 
data from the Web Server 206 via Forwarding Software s 
204. The Browser 205 executes an Applet 207 that is 
embedded by the Forwarding Software 204 into the re- 
trieved data. Applet 207 maintains a connection 208 to 
the Client Software 203 in the Proxy 202. Over connec- 
tion 208, the Applet receives commands from the col- 10 
laboration session and provides information that the Cli- 
ent Software 203 can disseminate to the collaboration 
session. Typically, the Applet 207 is written in the Java 
or JavaScript programming languages, which are stand- 
ard mechanisms for delivering software to Web Brows- '5 
ers in a browser-independent and platform-independent 
manner. 

Referring now to Figure 3, a flowchart depicts how 
Web data is retrieved by a Web Browser. At block 301 , 
the Web Browser transmits a data request to the For- 20 
warding Software embedded inside the Proxy. At block 
302, the Forwarding Software initiates a connection to 
the appropriate Web Server. At block 303, the Web 
Server receives the request and transmits data to the 
Forwarding Software. At block 304, the Forwarding Soft- 2s 
ware receives data from the Web Server and inserts an 
Applet into the data. At block 305, the Forwarding Soft- 
ware passes the retrieved data (with the inserted Applet) 
to the Browser. At block 306, the Browser receives the 
data, parses the data, displays the data, and executes <?<? 
the Applet The procedure then terminates at 307. Al- 
though not shown, it is understood that blocks 303, 304, 
and 305 may occur concurrently as data is streamed 
from the Web Server to the Forwarding Software to the 
Web Browser. Although the Applet is inserted by the ss 
Forwarding Software in the preferred embodiment, al- 
ternative embodiments may have the Applet inserted by 
the Web Server or statically present within the page. 

The Applet is responsible for initiating a connection 
to the Client Software (see Figure 2) so that the Web 40 
Browser may be linked with the collaboration even 
though arbitrary content has been loaded (pulled) into 
the Browser. When the Applet is inserted into the data 
retrieved from the Web Server, the Forwarding Software 
may provide parameter(s) that designate how that Ap- 
plet should connect to the Client Software. In addition, 
when the Web page contains "frames" representing 
multiple documents that are simultaneously visible, mul- 
tiple Applets may be active simultaneously. Conse- 
quently, the first Applet to run places itself into a global so 
variable, so that multiple Applets do not communicate 
with the Client Software simultaneously from within a 
single Web Browser. 

Once the Applet is executed, it sends an *addURL" 
message to inform the Client Software of which page is ss 
currently visible on the Browser window. When the Ap- 
plet is terminated, it sends a "removeURL" message no- 
tifying the Client Software that the page is no longer vis- 



ible. It may send ■readData" and "writeDAta" messages 
to respectively retrieve and store persistent information 
from and to the Proxy. Finally, the Applet listens for com- 
mands from the Client Software such as, for example, 
a request to load a new Web page into the Browser. 

Referring now to Figure 4A, a flowchart illustrates 
the actions performed by the Applet inserted by the For- 
warding Software when it executes in the Web Browser. 
At decision block 401 , the Applet checks whether or not 
the global variable is null. If the response to decision 
block 401 is yes, then in block 402, the Applet initializes 
the global variable to point to itself. In block 403, the 
Applet retrieves any connection parameters provided by 
the Forwarding Software. In block 404, the Applet initi- 
ates a connection to the Client Software. At block 405, 
the Applet sends an "addURL" message with the current 
page URL as a parameter over its connection to the Cli- 
ent Software. At this point, the Applet initiates three con- 
current execution paths through blocks 406, 408, and 
410. Referring to Fig. 4B, at decision block 406, the Ap- 
plet determines whether a command to load a new URL 
is received from the Client Software. If the response to 
decision block 406 is yes, then at block 407, the Applet 
notifies the Browser to load a new page and then returns 
to decision block 406. Concurrently, at block 408 (Fig. 
4C), the Applet determines whether or not it received a 
request from another Applet to add or remove a URL. If 
the response to decision block 408 is yes, then at block 
409 the Applet sends an "addURL" or "removeURL" 
message over its connection to the Client Software and 
then returns to decision block 408. Concurrently, at de- 
cision block 410 (Fig. 4D), the Applet determines wheth- 
er or not a stop message has been received from the 
Browser. If the response to decision block 410 is no, ex- 
ecution returns to decision block 410. If the response to 
decision block 410 is yes, then at block 41 1 , the Applet 
sends a "removeURL" message to the Client Software 
with the current page URL as a parameter. At block 41 2, 
the Applet terminates the connection to the Client Soft- 
ware. At block 413, the Applet restores the global vari- 
able to null. It then terminates at block 414. 

Continuing with Figure 4A, if the answer to decision 
block 401 is no, then at block 415, the Applet notifies 
the Applet represented by the global variable to add a 
URL. At this point, the Applet initiates two concurrent 
execution paths through blocks 416 and 417. At deci- 
sion block 416, the Applet determines whether or not 
the global variable is null. If the response to decision 
block 416 is no, execution returns to block 416. If the 
response to decision block 416 is yes, execution con- 
tinues to block 402. Concurrently, at block 417, the Ap- 
plet determines whether or not a stop message has 
been received from the Browser. If the response to de- 
cision block 417 is no, execution returns to decision 
block 417. If the response to decision block 417 is yes, 
then at block 418, the Applet notifies the Applet repre- 
sented by the global variable to remove this URL. The 
Applet then terminates at 414. 
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Within this collaborative system, the users may col- 
laborate with each other according to whether they are 
currently viewing the same page. When the Client Soft- 
ware receives an "addURL" or "removeURL" notifica- 
tion, it forwards the information to the MUSSS. With in- 
formation about the pages currently viewed by each us- 
er, the MUSSS is responsible for ensuring that collabo- 
rative data (including text and audio chat, whiteboard 
data, etc.) is exchanged among users who are seeing 
one or more documents in common on their respective 
Browsers or among groups of users as determined by 
the application. 

Through this collaboration system, users may par- 
ticipate in a "Tour.' In such a Tour, when a designated 
Leader "pulls' a new page into his Browser, the Brows- 
ers at one or more f ollowers" automatically load the 
same page. In this way, a group of users may concur- 
rently "pull 0 content from the Web while the collaboration 
system "pushes' information to ensure that the pages 
seen by the users are consistent. 

Referring now to Figure 5, the mechanis by which 
a user joins a Tour is illustrated. At block 501, the user 
selects a leader for the Tour. At block 502, the Client 
Software transmits a "follow" request including the lead- 
er's identity to the MUSSS. At decision block 503, the 
MUSSS determines whether or not the system is oper- 
ating in a peer-to-peer mode. If the response to decision 
block 503 is no, then at block 504, the server stores an 
association between the leader and the follower. The 
procedure then terminates at 505. If the response to de- 
cision block 503 is yes, then at block 506, the server 
forwards the "follow" request to the leader who, at block 
507, adds the follower to his own follower list. The pro- 
cedure then terminates at 505. Although not depicted in 
Figure 5, it is to be understood that the path through 
blocks 502, 503, and 506 may be shortened if the Client 
Software can determine that the system is operating in 
a peer-to-peer mode; in this case, the Client Software 
can transmit the "follow" request directly to the leader, 
as represented by block 502-A. 

Referring now to Figure 6, the mechanism by which 
followers are notified when a Tour leader moves to a new 
Web page is shown. In block 601, the Client Software 
receives an "addURL" message from the leader's Web 
Browser. At block 602, the Client Software forwards the 
"addURL" notification to the MUSSS. At decision block 
603, it is determined whether or not the system is oper- 
ating in a peer-to-peer mode. If the response to decision 
block 603 is no, then at block 604, the MUSSS sends 
"changePage" notifications to each of the leader's as- 
sociated followers. At block 605, the Client Software at 
a follower receives a "changePage" notification from the 
MUSSS. At block 606, the Client Software forwards the 
"changePage" notification to the Applet running in the 
local Web Browser. The process then terminates at 
block 607. If the response to decision block 603 is yes, 
then at block 608, the Client Software at the leader's 
host sends "changePage" notifications to each of the fol- 



lowers in the local follower list. Control then continues 
to block 605, as described above. 

Thus, the collaboration system can push informa- 
tion to all clients while simultaneously allowing them to 

5 pull arbitrary information from Web servers. Moreover, 
because control of the Browser is performed through an 
Applet written in Java, the collaboration system is inde- 
pendent of the particular machine or operating system 
environment and is independent of the particular Web 

*0 Browser in use. 



Claim© 

'5 t. A method of retrieving data from an information 
server, comprising the steps of: 

a requester initiating a request for data from an 
information server; 
20 sending said request to a Proxy; 

said Proxy forwarding said request to said in- 
formation server; 

said Proxy receiving and storing data from said 
information server; inserting an Applet into said 
25 data; 

delivering said data and said Applet to said re- 
quester of said data; and 
executing said Applet. 



2. The method of Claim 1 , wherein said step of exe- 
cuting said Applet further comprises the steps of: 

initiating a connection to Client Software; and 
terminating said connection to Client Software. 
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3. The method of Claim 2, further comprising the step 
of: 

sending an "addURL" notification over said 
connection to Client Software. 

4. The method of Claim 2, further comprising the step 
of: 

sending a "removeURL" notification over said 
connection to Client Software. 

5. The method of Claim 2, further comprising the step 
of: 

sending a "readData" request over said con- 
nection to Client Software. 



6. The method of Claim 2, further comprisinq the steo 
55 of: 

sending a "writeData" request over said con- 
nection to Client Software. 
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7. The method of Claim 2, further comprising the steps 
of: 

receiving a "changePage" notification over said 
connection to Client Software; and 
initiating the retrieval of new data in accordance 
with said "changePage" notification. 

8. The method of claim 7, further comprising the steps 
of: 

initiating a follow* request for a target leader 
from said Client Software; 
recording an identity of an originator of said "fol- 
low" request; and 

initiating a "changePage" request to said origi- 
nator as a result of actions taken by said target 
leader. 

9. The method of Claim 2 wherein said Client Software 
communicates with a Multi-User Shared State 
Server. 

10. The method of Claim 2, wherein said step of initiat- 
ing a connection to Client Software includes deter- 
mining an identity of a "global" Applet, and wherein 
said connection to said Client Software is a logical 
connection established by forwarding requests to 
said "global" Applet. 

11. The method of Claim 10, further comprising the 
steps of: 

monitoring for a presence of a "global' Applet; 
and 

becoming said "global" Applet should there be 
no said "global" Applet present. 

12. A system for retrieving data from an information 
server, comprising: 

means for a requester initiating a request for 

data from an information server; 

means for sending said request to a Proxy; 

means for said Proxy forwarding said request 

to said information server; 

means for said Proxy receiving and storing data 

from said information server; 

means for inserting an Applet into said data; 

means for delivering said data and said Applet 

to said requester of said data; and 

means for executing said Applet. 
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means for terminating said connection to Client 
Software. 

14. The system of Claim 13, further comprising: 

means for sending an "addURL" notification 
over said connection to Client Software. 

15. The system of Claim 13, further comprising: 

means for sending a "removeURL" notification 
over said connection to Client Software. 

16. The system of Claim 13, further comprising: 

means for sending a "readData" request over 
said connection to Client Software. 

17. The system of Claim 13, further comprising: 

means for sending a "writeData" request over 
said connection to Client Software. 

18. The system of Claim 13, further comprising. 

means for receiving a "changePage" notifica- 
tion over said connection to Client Software; 
and 

means for initiating the retrieval of new data in 
accordance with said "changePage" notifica- 
tion. 

19. The system of Claim 18, further comprising: 

means for initiating a follow" request for a tar- 
get leader from said Client Software; 
means for recording an identity of an originator 
of said "follow" request; and 
means for initiating a "changePage" request to 
said originator as a result of actions taken by 
said target leader. 



20. The system of Claim 13, wherein said Client Soft- 
ware communicates with a Multi-User Shared State 

45 Server. 

21. The system of Claim 13, wherein said means for 
initiating a connection to Client Software includes 
means for determining an identity of a "global" Ap- 

so plet, and wherein said connection to said Client 
Software is a logical connection established by for- 
warding requests to said "global" Applet. 



13. The system of Claim 12, wherein said means for 22. The system of Claim 21, further comprising: 
executing said Applet further comprises: 55 

means for monitoring for a presence of a "glo- 
means for initiating a connection to Client Soft- baT Applet; and 

ware and means for becoming said "global" Applet 
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should there be no said "global" Applet present. 

23. A computer readable storage medium having com- 
puter readable program code means for retrieving 
data from an information server, the computer read- 
able program code means comprising: 

computer readable program code means for a 
requester initiating a request for data from an 
information server; 

computer readable program code means for 
sending said request to a Proxy; 
computer readable program code means for 
said Proxy forwarding said request to said in- 
formation server; 

computer readable program code means for 
said Proxy receiving and storing data from said 
information server; 

computer readable program code means for in- 
serting an Applet into said data; 
computer readable program code means for 
delivering said data and said Applet to said re- 
quester of said data; and 
computer readable program code means for 
executing said Applet. 

24. The computer readable storage medium of Claim 

23, wherein said computer readable program code 
means for executing said Applet further comprises: 

computer readable program code means for in- 
itiating a connection to Client Software; and 
computer readable program code means for 
terminating said connection to Client Software. 

25. The computer readable storage medium of Claim 

24, further comprising: 

computer readable program code means for 
sending an "addURL" notification over said 
connection to Client Software. 



26. The computer readable storage medium of Claim 
24, further comprising: 

computer readable program code means send- 
ing a "removeURL" notification over said con- 
nection to Client Software. 

27. The computer readable storage medium of Claim 
24, further comprising: 
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computer readable program code means send- 
ing a "writeData" request over said connection 
to Client Software. 

29. The computer readable storage medium of Claim 
24, further comprising: 

computer readable program code means for re- 
ceiving a "changePage" notification over said 
connection to Client. Software; and 
computer readable program code means for in- 
itiating the retrieval of new data in accordance 
with said "changePage" notification. 

30. The computer readable storage medium of Claim 
29, further comprising: 

computer readable program code means for in- 
itiating a "follow" request for a target leader 
from said Client Software; 
computer readable program code means for re- 
cording an identity of an originator of said "fol- 
low" request; and 

computer readable program code means for in- 
itiating a "changePage" request to said origina- 
tor as a result of actions taken by said target 
leader. 
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The computer readable storage medium of Claim 
24, wherein said Client Software communicates 
with a Multi-User Shared State Server. 
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32. The computer readable storage medium of Claim 
24, wherein said computer readable program code 
means for initiating a connection to Client Software 
includes computer readable program code means 
for determining an identity of a "global" Applet, and 
wherein said connection to said Client Software is 
a logical connection established by forwarding re- 
quests to said "global" Applet. 

33. The computer readable storage medium of Claim 
32, further comprising: 

computer readable program code means for 
monitoring for a presence of a "global" Applet; 
and 

computer readable program code means for 
becoming said "global" Applet should there be 
no said "global" Applet present. 



computer readable program code means send- 
ing a "readData" request over said connection 
to Client Software. ss 



28. The computer readable storage medium of Claim 
24, further comprising: 
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FIG. 3 

301 

. Z_ 

Transmit data request to the 
forwarding embedded in the proxy 

I 302 
I / 

Forwarding software initiates 
connection to Web Server 

303 

. f <L- 

Web Server receives request and 
transmits data to Forwarding Software 

304 

. 1 <L- 

Forwarding Software receives data 
and inserts Applet into the data 

305 

, i ^ . 

Forwarding software passes modified 
data stream to Web Browser 

306 

i ^_ 

Browser receives data from forwarding 
software, parses and displays 
the data, and executes the Applet 
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Initialize global variable 
to point to self 




403 
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Retrieve connection 
parameter provided by 
Forwarding Software 
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Initiate connection 
to Client Software 




405 


Send "ac 
to Client i 


idURL" 

Software 
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Applet notifies "global" 
Applet to add this URL 




Notify "global" Applet 
to remove this URL 
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Tell Browser to 
Load new page 




Send an "addURL" or 
"removeURL" message 
to the Client Software 



FIG. 4D 




No 



Send "removeURL" 
with current page URL 
as a parameter 



412 

-2L_ 



Terminate connection 
to Client Software 
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Restore global 
variable to null 



414 
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FIG. 5 
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Select leader 




for Tour 
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Transmit follow" request 




toMUSSS 
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/ 



Transmit "follow" 
request to leader 




No 
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Forward •follow" 
request to leader 



Store association of 
leader to follower 
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Add follower 
to follower list 
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/ 

Client Software receives 
"addURL" from leader's 
Web Browser 
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FIG. 6 



Client Software forwards 
"addURL" notification 
toMUSSS 




Yes 
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Client Software at the leader's 
host sends "changePage" 
notification to each of the 
followers in the local follower list 



MUSSS sends "changePage' 
to each leader's 
associated followers 
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Follower Client Software 
receives "changePage" 



606 



Client Software forwards 
"changePage" to 
Web Browser 
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End 
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